1. The Field of the Invention
The present invention relates to systems and methods for extending the capability of email protocols used to transfer messages between mail servers. More specifically, the present invention relates to systems and methods that may be used to extend the SMTP or similar mail protocol to transfer additional data that is not defined in the mail protocols.
2. The Prior State of the Art
Although computers were once isolated and had minimal or little interaction with other computers, computers today interact with a wide variety of other computers through Local Area Networks (LANs), Wide Area Networks (WANs), dial-up connections, and so forth. With the wide-spread growth of the Internet, connectivity between computers is becoming more important and has opened up many new applications and technologies completely unthought of just a few short years ago. The growth of large-scale networks and the widespread availability of low-cost personal computers has fundamentally changed the way that many people work, interact, communicate, and play.
Electronic communications among users of various computer systems have been known for many years. Many companies have developed internal electronic mail systems that allow email communications between various computers connected to corporate LANs or other networks. Many companies have reengineered their processes and procedures to take maximum advantage of email communications in order to provide a convenient mechanism for exchanging information and documents, thus reducing the handling of paperwork and speeding the flow of information between and among employees of various departments. Traditionally, however, large-scale networks connecting various divisions over vast distances were extremely expensive. In addition, the large-scale networks which did exist generally used proprietary protocols were difficult to interconnect to other networks.
With the growth and development of the Internet, however, the situation has changed dramatically. Today, a company may install a corporate LAN at sites separated by large geographic distances and "backbone" communications between sites over the Internet. In many ways, the Internet has become a standard with which any viable network must interact.
TIraditionally, however, interaction with the Internet in order to backbone communications had many limitations. For example, until recently the Internet supported only plain text messaging. In contradistinction, many corporate LANs and other networks supported a wide array of rich text and other formatting features and allowed a wide variety of information to be exchanged among users. Thus, the Internet became a kind of "lowest common denominator" which provided basic functionality, but lacked support for many advanced features found in certain other networks. Although this situation is changing through the adoption of new standards for the Internet, the Internet still lags many advanced networking systems.
Standards for the Internet are documented in various "RFC" documents. The basic format of mail messages and transfer of mail messages is documented in RFC 821 and RFC 822, both of which are incorporated herein by reference. RFC 822 defines the various formats of an email message and RFC 821 defines the Simple Mail Transfer Protocol (SMTP) which is used to transfer 822 messages through the Internet. In essence, SMTP wraps the 822 message in an "envelope" and transfers the message between servers. The basic sequence of events which occur when a mail message is transferred using the SMTP protocol is 1) a connection is established between a sending server and a receiving server; 2) the sending server transfers the envelope information; 3) the sending server transfers the mail message; and 4) the sending server terminates the connection to the receiving server. The transfer of the envelope information is sometimes referred to as the 821 session and the transfer of the mail message is sometimes referred to as the 822 session. This is because the information defined in RFC 821 is transferred as the envelope and the information defined in RFC 822 is transferred as the mail message.
Because of the limited variety of information and formats that may be transferred as part of either the 821 or 822 session, information is occasionally lost when mail messages originate in one network and are backboned across the Internet to a second network. Information that does not directly translate into one of the defined parameters in either the 821 session or 822 session is often stripped when the mail message is forwarded through the Internet. In addition, even if information is not stripped, it may reside in the wrong session. For example, certain networks have or would like certain information to reside at a level analogous to the envelope while in the Internet such information is part of the 822 session. This requires a network desiring access to the information to decode each 822 message from the Internet and extract the desired information. If a message is forwarded between multiple servers using an SMTP protocol, in certain situations each server may have to decode the 822 message to retrieve the information. This is a time consuming and burdensome task. In addition to the above situations, many networks allow users to define information that is carried along as part of an email message in one or more custom data fields. Such custom information is lost when a message is transferred over the Internet due to the lack of support for custom information in the SMTP protocol and the 822 mail message.
Although various extensions have been defined for the SMTP protocol, there does not currently exist any extension which allows custom data or data extracted from the 822 mail message to be transferred as part of the 821 session. It would, therefore, be highly desirable to provide an extension to the SMTP or similar protocol which allowed any desired information to be transferred via the SMTP 821 session or similar protocol so that information loss can be minimized or eliminated. It would also be desirable to provide a mechanism to transfer desired information at a level which does not require the receiving server to decode the 822 message in order to have access to desired information.